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Distributed  Tactical  Decisiou  Support  to  a  theoretical  iaveetigation  being  performed  by  NOSC  for  ONE.  to  better 
understand  the  distributed  tactical  decision-making  process.  ReaVtlme  tracking  for  combat  direction,  using  a  distributed 
database  system  as  a  support  tool,  will  bo  used  at  a  baseline  for  anderstaading  that  process.  The  theory  next  will  be 
generalised  beyond  the  tracking  problem.  The  purpose  of  the  iaveetigation  to  to  develop  mechanisms  for  maximising  the 
quality  of  human  decision  making  and  improving  its  timeliness  in  suck  a  distributed  environment.  These  improvements  can 
best  be  attained  by  the  nnderataadiag  of  those  critical  factors  that  ensure  n  consistent  display  of  distributed  tactical 
information  at  all  levels  of  use. 

This  investigation  to  coaaldtring  the  knowledge  domain  of  tracking  la  n  combat  direction  system,  the  rules  that  must 
apply  to  that  domain  when  evaluating  n  possible  threat,  and  the  hamaa  interaction  required.  The  domain  of  mission 
planning  at  the  battle-group  level  will  be  considered  to  compare  concerns  for  timeliness  and  decision  quality.  Iaveetigatioa  of 
the  timing  and  memory  constraints  that  arise  when  trying  to  examine  why  n  particular  decision  was  made  in  either  domain 
alto  will  be  performed.  Examples  of  these  constraints  Include  the  unraveling  of  the  rules  that  were  applied  to  determine 
whether  a  given  track  was  hostile  (saa  hppeadleee  k  and'  B^or  the  analysis  of  why  a  combatant  was  deployed  at  a 
particular  time  aad  site  during  mission  planning.  ^ 
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Distributed  Tactical  Decision  Support  is  a  theoretical 
investigation  being  performed  by  NOSC  for  ONR  to  better 
understand  the  distributed  tactical  decision-making  process.  Real¬ 
time  tracking  for  combat  direction,  using  a  distributed  database 
system  as  a  support  tool,  will  be  used  as  a  baseline  for  under¬ 
standing  that  process.  The  theory  next  will  be  generalized 
beyond  the  tracking  problem.  The  purpose  of  the  investigation  is 
to  develop  mechanisms  for  maximizing  the  quality  of  human 
decision  making  and  improving  its  timeliness  in  such  a  distributed 
environment.  These  improvements  can  best  be  attained  by  the 
understanding  of  those  critical  factors  that  ensure  a  consistent 
display  of  distributed  tactical  information  at  all  levels  of  use. 

This  investigation  is  considering  the  knowledge  domain 
of  tracking  in  a  combat  direction  system,  the  rules  that  must 
apply  to  that  domain  when  evaluating  a  possible  threat,  and  the 
human  interaction  required.  The  domain  of  mission  planning  at 
the  battle-group  level  will  be  considered  to  compare  concerns  for 
timeliness  and  decision  quality.  Investigation  of  the  timing  and 
memory  constraints  that  arise  when  trying  to  examine  why  a 
particular  derision  was  made  in  either  domain  also  will  be  per¬ 
formed.  Examples  of  these  constraints  include  the  unraveling  of 
the  rules  that  were  applied  to  determine  whether  a  given  track 
was  hostile  (see  Appendices  A  and  B)  or  the  analysis  of  why  a 
combatant  was  deployed  at  a  particular  time  and  site  during 
mission  planning. 

The  tracking  model  is  based  on  the  birth/death  of  a 
contact  or  object,  whose  value  is  designated  as  a  track  number, 
together  with  time  of  entry  into  the  Combat  Direction  System 
(CDS).  The  model  captures,  via  transactions,  different  views  or 
opinions  of  information  on  the  contact  as  it  is  being  processed 
by  the  various  actions  of  the  CDS.  Time  0  (TO)  is  designated  as 
the  time  when  the  sensor  gains  contact  and  the  track  is  formed. 
The  "death”  of  the  contact  could  occur  because  of  loss  of  sensor 
contact,  because  of  contact  engagement,  or  because  of  reassess¬ 
ment  as  a  contact  with  a  different  value.  Between  “birth  and 
death”  occur  a  number  of  steps  or  actions  required  to  determine 
the  identity  and  location  of  the  contact.  In  each  case,  severe 
real-time  constraints  must  be  met. 

In  the  framework  of  the  model,  dynamic  contact  infor¬ 
mation  consisting  of  tracking  data  will  be  input  into  a  centralized 
computer  database  and  broadcast  to  the  CDS  operator  consoles 
for  intelligent  machine-based  analysis;  i.e.,  for  Remote/Radar/ 
Electronic  Support  Measures  (ESM)  console(s)  and  Area  Sector 
console(s).  A  console’s  view  of  its  tracks  can  be  inconsistent 
with  another  console's  view  of  those  tracks.  These  views  can 
become  consistent  for  a  number  of  different  reasons,  while  still 
obeying  the  rules  of  operation  established  when  the  consoles 
are  operating  independently.  The  time,  amount  of  communica¬ 
tion  required,  track  quality  (or  confidence  level),  number  of 
operators  involved  in  achieving  a  consistent  consensus  view  of 


the  track,  and  assessment  of  risk  in  assuming  that  concensus 
will  be  analyzed.  The  results  will  be  compared  to  achieving  that 
view  by  using  a  centralized  database  and  traditional  statistical  cor¬ 
relation  techniques  |  Ref.  I ) . 

Relative  performance  measurements  for  timeliness  and 
information  confidence  are  being  gathered  by  means  of  a  NOSC- 
distributed  tracking  model  testbed  (see  Figure  I)  configured  of 
three  SUN  3/SOMs,  each  supported  by  a  hand-disk  drive,  provid¬ 
ing  the  Berkeley  4.2BSD  distributed  version  of  UNIX  and  inter¬ 
connected  via  Ethernet.  These  measurements  will  show  the 
advantages/disadvantages  of  distributed  decision  making  in  the 
tracking  of  detected  contacts.  The  hypothesis  to  be  tested  is 
that  of  showing  that  more  responsive  decisions  can  be  made  with 
better  quality  (more  confidence)  than  today’s  centralized 
systems  provide. 

THEORETICAL  APPROACH: 

The  method  used  in  this  investigation  includes  optimizing 
the  querying  of  the  database  (see  Figure  2  and  Ref.  2 1  in  sup¬ 
port  of  the  real-time  distributed  tracking  problem.  Machine- 
based  reasoning  will  be  used  to  determine  why  a  particular  query 
should  or  should  not  be  accomplished.  An  example  would  be  a 
comparison  of  platform  track  speed  versus  maximum  air  contact 
speeds  in  the  database  to  assess  what  the  threat  could  or  could 
not  be  (i.e.,  not  a  helicopter  because  its  speed  is  too  great),  or 
to  establish  how  quick  the  platform's  course  can  be  changed.  In 
such  cases,  the  check  is  on  whether  the  value  of  an  attribute  is 
legal  or  not;  that  is,  have  the  constraints  been  satisfied?  (See  the 
logic  of  radar,  remote,  and  Electronic  Support  Measures  |ESM) 
track  constraints  and  associated  transactions  in  Appendix  A). 

The  next  step  would  be  either  the  development  of  a  reasoning 
chain  for  analyzing  the  characteristics  of  the  track  (see  the  logic 
of  correlation  transactions  in  Appendix  B)  or  the  development  of 
the  reasoning  chain  for  mission-planning  actions. 

This  effort  is  a  spinoff  from  research  that  D.  Small  of 
NOSC  did  in  collaboration  with  Dr.  Wesley  Chu  of  UCLA  in 
1 979  |  Ref.  3 )  on  expert  systems  processing  for  distributed  data¬ 
base  systems  in  the  dynamic  Navy  environment,  and  from  Dr. 
Lui  Sha’s  (CMU)  research  in  modular  concurrent  processing  for 
real-time  databases  (Ref.  4] .  There  have  been  a  number  of 
articles  on  real-time  systems,  but  in  only  a  few  instances  has 
there  been  discussion  on  real-time  database  systems.  The  more 
notable  of  these  include  Dr.  Roger  King’s  (U.  of  Colorado) 
research  in  semantic  query  optimization  and  time  management, 
using  versions  for  relational  databases  ( Ref.  $  ] .  Dr.  Chu’s  work 
in  optimal  query  processing  for  distributed  database  systems 
I  Ref.  6] ,  and  Dr.  M.  Singhai's  (University  of  Maryland)  research 
in  time  stamping  for  real-time  database  management  |Ref.  7) . 

The  expert  system  processing  model  for  distributed  data¬ 
base  systems  |Ref.  3)  and  L.  Sha's  concurrent  processing  model 
|  Ref.  4]  will  form  a  design  basis  for  determining  where  the 
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Figure  1 .  NOSC  distributed  tactical  decision  support  tracking  model  testbed  (using  SUN  processors). 
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various  knowledge  elements  reside.  Based  on  this  framework, 
legal  values  of  the  knowledge  elements  will  be  derived.  By  using 
such  values,  rules  will  be  developed,  for  example,  to  deteimine 
the  potential  threat  of  a  contact  or  target  being  tracked  or  to 
determine  plans  for  weapon  allocation.  At  any  time  in  the 
analysis  of  a  mission's  progress— be  it  threat  analysis,  weapon 
allocation, or  platform  positioning-the  distributed  expert 
decision-making  model  will  be  able  to  recover  dated  information 
and  install  it,  as  appropriate,  as  current  knowledge  1  Ref.  5  and 
7 ) .  Then  it  will  unravel  why  any  particular  decision  was  made 
and  assess  the  impact  of  that  decision  if  it  is  followed  to  comple¬ 
tion.  The  following  sections  of  this  paper  will  show,  in  consider¬ 
ably  more  detail,  how  various  design  alternatives  using  this 
approach  art  being  pursued. 

DISTRIBUTED  TACTICAL  DECISION-MAKING 
ANALYSIS  ALTERNATIVES: 

Distributed  tactical  decision-making  alternatives  being 
considered  in  this  year's  (1987)  research  are  two-fold.  (Other 
alternatives  will  be  considered  next  year.)  Figure  3  considers 
the  alternative  of  track  information  being  received  from  appli¬ 
cable  Similar  Source  Integration  (SSI)  radar  or  ESM  functions,  or 


from  remote  tracks.  This  information  is  input  at  time  =  0  to  the 
centralized  computer  database  resident  in  the  Battle  Force  Track 
File  (BFTF)  database,  as  modeled  in  Figure  2.  In  parallel,  track 
information  is  sent  to  the  Dissimilar  Source  Integration  (DSI) 
consoles  by  the  CDS  system  according  to  operator  needs.  The 
operator's  information  may  be  sent  according  to  doctrine  as  to 
what  he  should  be  monitoring,  or  according  to  the  commanding 
officer's  request  for  more  information  as  he  attempts  to  charac¬ 
terize  a  track  as  threatening  or  not.  These  is  no  concern  in  this 
alternative  as  to  whether  a  track  already  has  been  integrated  with 
other  sources  into  a  global  track  before  mote  global  track  corre¬ 
lation  processing  is  done. 

Initially,  consoles  will  be  assigned  global  track  correlation 
processing  responsibility  by  console  type,  such  as  by  radar, 
ESM,  and  remote  sensor  data  source  types;  and  for  the  con¬ 
tact  types  surface,  subsurface,  and  aircraft,  according  to  sector 
areas  as  shown  in  Figure  3.  Rules  are  established  as  to  when  a 
console  must  communicate  with  other  consoles.  An  example 
could  be  the  ESM  console's  need  to  know  more  information 
about  a  track's  position  because  of  a  sensor’s  indication  that  a 
track  is  likely  hostile.  An  issue  is  how  much  of  this  type  of 
communication  is  required  in  this  alternative  before  the  system’s 
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communication  mechanisms  become  overloaded,  tach  console 
can  be  considered  to  be  working  serially  and  independently  on  its 
own  set  of  tracks  to  determine  their  identification  and  location. 
There  is  no  guarantee  that  the  tracks  are  separate  and  distinct 
between  consoles.  Likewise  there  is  no  guarantee  that  a  track 
being  watched  on  one  console  was  received  at  the  same  time  by 
the  CDS  system  as  that  same  track  being  monitored  at  another 
console.  An  example  of  such  serialized  processing  could  consider 
each  console  as  having  a  short  track  history,  so  that,  when  the 
operator  receives  a  track  report  with  an  ellipse  of  uncertainty, 
he  would  attempt  to  match  that  track  with  his  track  history.  He 
would  assess  the  identification  of  the  track  based  on  evidence  as 
to  whether  the  track  had  its  fire  control  on,  or  whether  there  was 
an  indication  of  any  other  threatening  maneuver  such  as  an 
abrupt  change  of  course  and  speed,  or  abrupt  communication 
silence.  Those  track  data  will  be  kept  internally  consistent  by 
maintaining  the  constraint  rules  described  in  the  Theoretical 
Approach  section  of  this  paper.  Serialized  processing  of  the 
analysis  (or  global  track  correlation)  of  a  track's  location  and 
identification  (described  in  Appendix  B)  can  be  interrupted  by 
the  receipt  of  a  new,  “very  important”  track,  such  as  a  new  track 
believed  to  be  hostile,  which  MUST  be  included  in  the  console's 
global  database.  In  this  instance,  the  ongoing  analysis  would  be 
halted  and  rolled  back  to  a  recoverable  start  point. 


A  second  alternative  (see  Figuie  4i  would  be  that  of 
minimizing  the  global  track  processing  by  only  doing  correlation 
processing  on  new  tracks  or  on  those  tracks  which  have  radical 
changes.  A  new  report  arriving  will  be  a  candidate  for  a  “global 
track”  if  its  quality  exceeds  a  certain  confidence  level  threshold. 
Once  it  exceeds  that  threshold  level,  it  either  has  established  an 
association  with  other  local  level  tracks  via  correlation  or,  vac¬ 
uously,  it  is  a  global  track  if  no  association  has  yet  been  estab¬ 
lished.  The  model  consists  of  two  levels  for  this  alternative,  the 
local  level  (combining  the  local  sensor  level  with  the  Similar 
Source  Integration  level)  and  the  Dissimilar  Source  Integration 
(DSI)  level.  The  local  level  has  its  own  local  track  database  and 
a  global  track  database  (global  track  numbers  for  local  tracks).  If 
a  new  report  already  has  a  global  track  number,  and  there  are  no 
significant  changes,  the  local  history  will  be  updated  and  correla¬ 
tion  will  not  be  attempted  at  the  DSI  level.  The  DSI  level  consists 
of  a  Global  Track  database  and  "candidates’’  for  a  global  track. 

If  a  “candidate"  passes  the  correlation  criteria,  it  is  given  a 
unique  global  track  number  that  is  propagated  downwards  to  the 
local  level  (inserted  in  their  global  track  databases).  This  alterna¬ 
tive  is  described  in  more  detail  in  working  papers  developed 
jointly  by  NOSC  and  Carnegie  Mellon  University  in  March  1987 
(Ref.  8)  Its  theory  is  based  on  the  assumption  that  a  track  is  an 
atomic  data  set  (ADS)  I  Ref.  4( ,  the  smallest  data  unit  that  can 


be  synchronized.  Elementary  transactions  |Kef.  4 1  on  such  ADSs 
include  local  constraint  and  association  transactions  and  global 
track  correlation  (see  Appendices  A  and  B).  In  all  cases  the 
execution  of  these  transactions  must  preserve  the  constraint  or 
consistency  rules  established  on  entry  of  the  track  into  the  SSI/ 
DSI  processing  levels  to  ensure  correctness.  For  example,  a 
track’s  correlation  processing  cannot  be  interrupted  without 
preserving  its  state  before  the  correlation  started,  therefore  pre¬ 
serving  the  correctness  of  the  transaction. 

In  both  alternatives,  a  console’s  view  of  its  tracks  can 
be  inconsistent  from  another  console's  view  of  those  tracks. 

For  example,  in  the  Tint  alternative,  the  air/radar  console’s  view 
of  an  air  contact's  identification  could  indicate  it  to  be  friendly, 
whereas  the  ESM  console's  view  of  that  same  contact  could  see 
it  as  having  an  identification  of  hostile.  These  views  can  be 
consistent  for  a  number  of  different  reasons,  while  still  obeying 
the  constraint  rules  established  when  the  consoles  are  operating 
independently.  First,  the  console  operator  may  receive  new 
information  on  the  track  as  it  is  broadcast  from  the  centralized 
BFTF  database.  Second,  a  console  operator  may  request  help 
from  the  other  console  operators  in  identifying  a  track  he  feels 
to  be  hostile.  Third,  it  could  be  that  a  console  or  group  of 
consoles  might  become  overloaded  with  responsibility  for 
too  many  tracks,  so  that  the  responsibility  would  be  shifted 
to  less  lightly  loaded  consoles,  forcing  data  consistency  to  be 
resolved  when  the  console  locations  are  changed.  The  main 
computer  also  could  change  a  console’s  responsibilities  because 
of  a  change  in  perceived  threat,  such  as  noting  a  target  in  close 
proximity  and  assigning  responsibility  for  that  target  to  an 
appropriate  console  in  a  nearby  sector.  Or  console  operators, 
either  by  doctrine  or  by  direction  from  the  Tactical  Action 
Office  (TAO)  and/or  the  commanding  officer,  arc  told  they 
must  report  to  him  all  hostile  identifications  within  a  pre¬ 
selected  radius  of  ownship,  forcing  a  consensus  view  of  differing 
opinions. 

In  both  alternatives,  whenever  a  track  is  agreed  to  be 
hostile,  the  next  step  will  be  the  sending  of  its  value  to  the  Multi- 
Warfare  Control  (MWC)  and  Mission  Control  (MC)  budding 
blocks  of  CDS.  The  MWC  building  block  will  support  the  action 
of  weapon  assignment  and  subsequent  scheduling  and  engage¬ 
ment.  This  action  would  be  based  on  threat  evaluation  data  or 
weapon  status,  among  other  things.  The  MC  building  block 
supports  the  information  needs  of  users  in  other  systems  support¬ 
ing  the  battle  group,  which  need  a  complete  accurate  assessment 
of  the  tactical  situation.  MC  and  MWC  operator  consoles  will  be 
modeled  only  as  to  time  to  assess  the  threat  and  validity  of  that 
assessment.  Engagement  will  be  considered  the  “death  of  a  con¬ 
tact"  and  an  end  time  will  be  assigned  to  that  track. 

COMBAT  DIRECTION  SYSTEM  (CDS) 

OPERATOR  CONSOLE  CAPABILITIES; 

Each  DSI  and  SSI  operator  console  will  be  provided 
automated  capability  for  database  management  update,  search, 
and  analysis  using  the  relational  join  and  restrict  functionality. 
Scheduling  of  those  functions  will  be  provided,  as  will  the 
scheduling  of  requests  of  other  consoles  or  of  the  main  processor 
for  information  such  as  tracks  within  the  radius  of  “x,”  hostiles 
in  that  radius,  or  changes  in  ID.  All  data  used  by  the  operator 
will  be  resident  in  the  console  processor’s  main  memory  or  sent 


either  on  a  predetermined  basis  or  by  operator  request.  Different 
profiles  or  contexts  of  expertise  to  be  provided  for  the  operator 
will  be  preselected  for  the  console  processor’s  memory,  probably 
from  the  BFTF  database.  Appendices  A  and  B  are  the  first 
attempt  at  the  modeling  of  such  capabilities. 

RELATIVE  MEASUREMENTS  FOR  ANALYSIS 
OF  ALTERNATIVES 

A  number  of  measurements  have  been  alluded  to  in  the 
Background  and  the  Distributed  Tactical  Decision-Making 
Analysis  Alternatives  sections  of  this  paper.  In  all  cases,  they 
evolve  around  the  timeliness  and  quality  of,  and  personnel  in¬ 
volved  in,  the  decisions  made.  In  this  paper,  there  is  no  attempt 
to  go  into  details  on  the  experimental  design  for  gathering  these 
measurements,  but  rather  a  first  attempt  to  solidify  the  types  of 
measurements  to  be  gathered.  In  all  cases,  an  attempt  will  be 
made  to  compare  the  approach  of  distributed  tactical  decision 
making  with  what  today's  centralized  systems  provide  |  Ref.  1  ] . 

Specifically,  the  measurements  include  the  average  time 
required  for  the  operator  to  decide  the  threat  potential  for  each 
report  entering  the  system.  The  time  required  for  a  reversal  of  a 
decision  can  also  be  measured,  for  example,  the  time  required  to 
agree  to  a  change  in  identification  from  hostile  to  friendly.  The 
quality  of  data  (i.e.,  number  of  decision  errors  over  time)  can  be 
measured  as  well.  For  each  decision,  a  determination  will  be 
made  of  how  many  operators  arc  involved  and  the  amount  of 
communications  required  in  the  achievement  of  a  consensus  view 
of  that  decision.  There  will  be  an  attempt  to  categorize  these 
data  by  the  type  of  decision  made;  for  example,  determination  of 
radical  change  in  a  track’s  history,  or  change  in  identification. 

An  assessment  of  risk  for  each  alternative  will  be  shown  as  a 
function  of  how  much  information  was  available  to  the  decision 
maker  at  any  given  time. 

At  the  engineering  level  of  design  for  each  console,  a  first- 
cut  analysis  will  be  made  of  how  much  information  can  reside 
reasonably  at  each  level,  based  on  processor  size,  speed,  and  avail¬ 
able  memory.  Secondly,  an  analysis  of  processor  bottlenecks 
will  be  considered,  such  as  how  much  database  locking  must 
occur  in  a  distributed  database  environment  like  the  one 
discussed,  and  the  effects  on  report  analysis  time. 

OTHER  EXPERIMENTAL  ALTERNATIVES: 

The  results  gathered  from  the  research  will  be  analyzed 
by  using  deliberate  insertion  of  time-latent  versions  of  track 
reports  (track  ADSs).  based  on  Dr.  Roger  King's  dau  object 
theory  |Ref.  SI  and  Dr.  M.  Singhai’s  research  in  time  stamp¬ 
ing  (Ref.  7) .  That  analysis,  together  with  the  tracking  model 
alternative  using  Carnegie  Mellon  University’s  Modular  Con¬ 
currency  Control  (MCC)  theory,  will  aid  in  the  application  of 
MCC  for  the  feeding  of  valid  Combat  Direction  System  (CDS) 
track  data  to  information  systems  supporting  the  battle  group. 

In  the  problem  of  mission  control  and  planning,  the  next  step 
will  be  the  incorporation  of  resource  allocation  theory  |Ref  9| 
to  help  in  the  development  of  rules  for  the  planning  of  platform 
deployment  or  weapon  allocation  (as  examples).  In  all  instances, 
relative  performance  measurements  will  be  taken  and  perfor¬ 
mance  analysis  done  and  compared  with  the  tracking  problem 
described  above. 
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APPENDIX  A 


CONSTRAINT  AND  ASSOCIATION  TRANSACTION  LOGIC 

{  pdl  for  radar  local  track  } 

if  (  quality  >  30%  )  then 
calculate  range, speed,  and  etc 
update  tuple  with  range, speed,  and  etc 

if  (  meets  ntds_max  constraints  for  ntd_class  )  then 
if  (  associated  i.e.  has  glbl  trk  •  )  then 
update  local  history 
end  if 

if  (  new  report  or  significant  changes)  then 
{  lock  potential  } 

correlate  at  global  level  {talk  to  ETC_GLOBAL_TRACK_TRANS } 
end  if 

else 

append  report  to  do_not_meet_rad_constraints  file 
end  if 
end  if 


{  pdl  for  remote  association  } 

calculate  range, speed,  and  etc 

if  (  associated  i.e.  has  glbl  trk  t  )  then 
update  local  history 

end  if 

if  (  new  report  or  significant  changes)  then 
{  lock  potential  } 

correlate  at  global  level  {talk  to  ETC  GLOBAL  TRACK  TRANS) 

_ _ i  :  r 


{  pdl  for  esm  (electronic  support  measure)  local  track) 

if  (  quality  >  30%  )  then 

if  (  meets  esm  constraints  for  platform_kind  in 
pkind_sen_con8traint 

and  ntds_clas8  in  ntds_sen_constraints)  then 

if  (  associated  {i.e.  has  glbl  trk  #}  )  then 
update  local  history 
end  if 

if  (  new  report  or  significant  changes)  then 
{  lock  potential  } 

correlate  at  global  level  {talk  to  SENSOR_GLOBAL_TRACK_TRANS } 
end  if 

else 

append  report  to  do_not_meet_esm_constraints  file 
end  if 

end  if 


APPENDIX  B 


CORRELATION  TRANSACTION  LOGIC 

{pdl  for  etc  (estimated  time  o£  contact)  global  track  correlation 

if  (outside  of  sector  1  and  2)  then 

send  track  information  to  that  sector's  console 

else 

if  (  (report  has  significant  changes  and  a  global  track  number) 
(quality  <  90%)  or  (  track  unknown)  )  then 
correlate 
else 

case  for  track  report 

quality  >*  90  and  confirmed  friendly: 
assign  new  global  track  number 
send  report  back  to  local  level 
don't  correlate 

{  release  lock  potential  -  done  below  } 

quality  >*  90  and  confirmed  hostile  and  (range  too  close  or 
etc  too  soon): 

repeat 

until  (request  for  verification  from  other 
operators  is  answered  ); 
if  (  agree  )  then 

notify  TAO  and  weapons  control 
send  track  report  information  to  weapon  control 
end  if 

send  all  information  to  local  level 
don't  correlate 

{  release  lock  potential  -  done  below  } 
otherwise  :  correlate 
end  case 
end  if 

if  (  correlate  )  then 

if  (  report  has  global  track  number(gtn)  )  then 
if  (  report's  id  disagrees  with  its  gtn's  current  id  and 
quality  >=  90%)  then 
delete  gtn's  history 
resolve  differences 
else 

if  (  report's  id  disagrees  with  its  gtn's  history  id  )  then 
if  (  quality  >■=  90%  )  then 
delete  gtn's  history 
end  if 

resolve  differences 

else 

don't  resolve  differences 
end  if 
end  if 
else 

resolve  differences 
end  if 

if  (  resolve  differences  )  then 
repeat 

get  global  track  (gt) 

if  (platform  kind  of  gt  matches  )  then 

if  (  speed  of  gt  is  within  constraint  for  report)  then 
if  (  range  and  etc  within  limits  for  report)  then 


if  (  course  vhithin  limits  for  report  )  then 
record  gt  number  in  list  of  possible  matches 
end  if 
end  if 

end  if 
end  if 

until  (  report  is  tested  against  all  the  global  tracks) 
if  (  more  than  one  match  )  then 

repeat 

if  (  history  indicates  radical  range/etc/course 
change  in  track  )  then 
remove  from  list  of  possible  matches 
end  if 

until (  all  possible  matches  processed  ) 
end  if 

if  (  more  than  one  match  )  then 
call  sensor  global  track  correlation  with  new  report 
intersect  its  response(s)  with  our  list  of  possible  rfiatches 
end  if 

if  (  one  match  )  then 

change  new  global  track  number  to  the  match's  track  number 
insert/merge  new  report  on/with  match's  history  stack 
{  release  lock  potential  -  done  below  ) 
else 

if  (  no  matches  )  then 

request  help  from  other  operators 
if  (  other  operators  identify  the  new  report  )  then 
add  new  report  as  new  track  to  etc  global  db 
{  release  lock  potential  -  done  below  } 
else 

use  centralized  system  for  correlation  calculation 
add  new  report  as  new  track  to  etc  global  db 
{  release  lock  potential  -  done  below  } 
end  if 

else  {  more  than  one  match  ) 

put  a  copy  of  the  new  report  on  the  history  stack 
for  each  of  the  possible  matches 
{  release  lock  potential  -  done  below  } 
end  if  {  no  matches  } 
end  if  {  match  } 
end  if  {  resolve  differences  } 
end  if  {  correlate  } 
end  if  {  outside  sectors  1  &  2  } 

release  lock  potential 
return  results  to  local  level 


{pdl  for  sensor  global  track  correlation  } 

repeat 

repeat 

if  (  new  track's  sensors,  id,  and  platform  kind  match  the 
track  being  processed  )  then 
add  track  to  possible  match  list 
end  if 

until  (  new  report  is  tested  against  all  the  global  tracks  ) 
if  (  more  than  one  match  )  then 
back  up  one  point  in  time 
end 


until  ((  one  match  )  or  (  last  data  point  reached  )) 

if  (  one  or  more  match  )  then 

if  (  new  report  is  hostile  )  then 

determine  weapon  with  greatest  range  and  speed  for  the  platforms 
with  the  sensor  of  the  new  report 
call  weapon  sub-transaction 

{  more  processing  of  results  of  call  -  to  be  determined  } 
send  results  of  processing  to  etc  global  track  transaction 
end  if 

update  the  global  db  {used  by  both  sensor  and  global  trans.  } 

{  lock  potential  between  sensor  and  etc  global  trans.  if 
on  different  nodes  } 

send  information  back  to  calling  process 
{  release  lock  potential  } 
else  {  no  match  } 

put  copy  of  new  report  in  global  db 
send  back  to  local  level 
end  if 


{  pdl  for  weapon  sub-transaction  } 
repeat 

calculate  weapon  etc  to  own  ship 
repeat 

if  (current  track  and  track  in  global  db  have  approx,  the  same 
maximun  range  and  weapon  speed  )  then 
add  the  track  to  possible  match  list 
until  (  all  tracks  in  global  db  have  been  checked  ) 
until  (  all  track  sent  to  this  process  checked) 

return  possible  match  list  to  sensor  global  track  transaction 


